A communication session may involve a persistent interactive exchange of information between two or more communicating entities (e.g. devices, applications, etc.). A communication session is established at a certain point in time, and torn down at a later point in time based on various circumstances (e.g. after the session times out or when one of the entities decides to terminate the session). A communication session may involve the exchange of multiple messages between entities and may be stateful. Stateful may mean that at least one of the communicating entities saves information about the session history in order to be able to maintain the communication session (e.g., security context such as credentials, identifiers, etc.).
A conventional application session is a communication session between two or more applications that is established and managed by the applications themselves rather than by an underlying communication protocol or service layer. As a result, application sessions can add extra overhead and complexity to applications.
A machine-to-machine (M2M) service layer is an example of one type of application service layer specifically targeted towards providing value-added services for M2M type devices and applications. For example, an M2M service layer can support Application Programming Interfaces (APIs) providing applications and devices access to a collection of M2M centric capabilities supported by the service layer. A few examples include security, charging, data management, device management, discovery, provisioning, and connectivity management. These capabilities are made available to applications via APIs which make use of message formats, resource structures and resource representations defined by the M2M service layer.
A machine-to-machine (M2M) service layer session is a communication session established between an M2M service layer instance and either an M2M application or another M2M service layer instance. An M2M service layer session can consist of M2M service layer state related to connectivity, security, scheduling, data, context, etc. This state can be maintained by the M2M service layer, an M2M application, or both.
There are multiple machine-to-machine (M2M) architectures with service layers, such as European Telecommunications Standards Institute (ETSI) M2M service layer discussed in draft ETSI TS 102 690 1.1.1 (2011-10), the Open Mobile Alliance (OMA) Lightweight M2M service layer discussed in draft version 1.0-14 Mar. 2013, and the oneM2M service layer discussed in oneM2M-TS-0001 oneM2M Functional Architecture-V-0.1.2. M2M service layer architectures (e.g., ETSI M2M, OMA LWM2M, and oneM2M). Another example of an application service layer is the IP Multimedia Subsystem (IMS) service layer TS 23.228, 3rd Generation Partnership Project that is specifically targeted to providing multimedia services for mobile network devices. These architectures may lack support for end-to-end security services (e.g., end-to-end encryption and authentication), end-to-end quality of service functionality (e.g., end-to-end latency or bandwidth guarantees), and end-to-end negotiation of settings or configuration (e.g., negotiating a type of compression used), as discussed herein.
Conventional methods of supporting end-to-end (E2E) sessions rely on applications and/or end users to establish and manage E2E sessions. This is an over-the-top methodology that results in overhead and added complexity to applications and/or the need for users to take part in session management. This over-the-top method also prevents network services from providing value-added session functionality such as data aggregation and data analytics, since data is encrypted by the applications in an E2E fashion and hence is not able to be processed securely by services in the network. Many M2M use cases require E2E sessions. For example, use cases using end-to-end security and privacy such as eHealth, banking, and military, as well as use cases using end-to-end quality of service such as video surveillance, patient monitoring, and emergency services. In addition, many M2M devices are unmanned, which also presents challenges for managing end-to-end sessions. For example, unmanned devices cannot rely on a user to generate, dynamically, a secure end-to-end session each time a session needs to be established.